home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / mac / files / infodata / bbs_if.txt < prev    next >
Internet Message Format  |  1996-06-25  |  25KB
  1. Path: news.unomaha.edu!crcnis1.unl.edu!wupost!cs.utexas.edu!uunet!news.mentorg.com!hpcan240.mentorg.com!wv.mentorg.com!hanko
  2. From: hanko@wv.mentorg.com (Hank Oredson)
  3. Newsgroups: rec.radio.amateur.digital.misc
  4. Subject: BBS specification
  5. Date: 16 Nov 1993 18:54:08 GMT
  6. Organization: Mentor Graphics, Wilsonville, Oregon, USA
  7. Lines: 852
  8. Distribution: world
  9. Message-ID: <2cb7kg$93l@wvhpadm1.mentorg.com>
  10. Reply-To: Hank_Oredson@mentorg.com
  11. NNTP-Posting-Host: hanko.mentorg.com
  12.  
  13.  
  14. Changes:
  15.  
  16. CTL-C not really restricted character?
  17. LF not used as alternate EOL
  18. Added info from AA4RE on "M in SID".
  19.  
  20. ...  Hank
  21.  
  22.  
  23.   BBS Interface Specification
  24.   Working Draft
  25.   11/13/93
  26.  
  27.  
  28.   Introduction
  29.   Section 1 - Establishing connection
  30.   Section 2 - Forwarding
  31.   Section 3 - Reverse forwarding
  32.   Section 4 - Forwarding to old BBSs
  33.   Section 5 - Error Conditions
  34.   Section 6 - BNF Summary
  35.   Section 7 - Feature Letter Use
  36.  
  37.  
  38.   Current mailing list
  39.   BBS_authors@arasmith.com
  40.  
  41.               bob@arasmith.com (Bob Arasmith, N0ARY)
  42.               hank_oredson@mentorg.com (Hank Oredson, W0RLI)
  43.               wd6cmu@netcom.com (Eric Williams, WD6CMU)
  44.               enge@almaden.ibm.com (Roy Engehausen, AA4RE)
  45.               71151.720@CompuServe.COM (Victor Poor, W5SMM)
  46.               blloyd@axion.bt.co.uk (Brian Lloyd, G1NNA)
  47.               map@hopper.cba.csuohio.edu (Mike Pechura, WA8BXN)
  48.               durham@w2xo.pgh.pa.us (James Durham, W2XO)
  49.               johan@ece.orst.edu (Johannes Reinalda, WG7J)
  50.               trentin@enac.dgac.fr (to J-P Roubelat, F6FBB)
  51.               sproul@sproul.com (Mark Sproul, KB2ICI)
  52.               mike@km6px.arasmith.com (Mike Stickney, KM6PX)
  53.               70007.1365@compuserve.com (Ed Juge, W5TOO)
  54.               73126.3260@compuserve.com (Craig McCartney, WA8DRZ)
  55.  
  56.   Via US Mail
  57.             Michael Jaggers, WB4TTZ
  58.                 1377 Columbia Ave, Franklin, TN  37064
  59.  
  60.   Introduction -
  61.   This document is meant to define the interaction between two BBSs
  62.   exchanging messages. It is not the goal of the document to specify
  63.   the interface of the future but merely represent what a BBS can be
  64.   expected to see at the current time.
  65.  
  66.   It is hoped that this specification will be followed by another that
  67.   defines the base rules for all BBS programs to adopt. This should
  68.   eliminate the current problems with incompatibilities and overloaded
  69.   operators. If you create a BBS to this specification you should be
  70.   able to interconnect with virtually any BBS currently in use. Any
  71.   extensions you add will put you at risk, the subsequent spec is to
  72.   identify these areas.
  73.  
  74.   In brief the following sequence of events takes place when the BBSs
  75.   connect for forwarding:
  76.  
  77.  
  78.   Master System             Slave System
  79.   ------------                --------------
  80.   {Connect}
  81.                     [SID]
  82.                     N9ZZZ >
  83.  
  84.   [SID]
  85.  
  86.                     >
  87.  
  88.   SB ARES @ ALLCA < W7ZZZ $ARES0108
  89.  
  90.                     OK
  91.  
  92.   message subject
  93.   message routing headers
  94.   message body
  95.   /EX
  96.  
  97.                     >
  98.  
  99.   SB WANT @ ALLUS < W8AAA $1029_N0XYZ
  100.  
  101.                     NO
  102.                     >
  103.  
  104.   F>
  105.  
  106.                     SP WA2ABC @ N2AAA < N9AAA
  107.  
  108.   OK
  109.  
  110.                     message subject
  111.                     message routing headers
  112.                     message body
  113.                     /EX
  114.  
  115.   F>
  116.  
  117.                     {Disconnect}
  118.  
  119.   This represents a simple example of connecting, establishing a common
  120.   protocol, forwarding and reverse forwarding. This document will look
  121.   more closely at each of these phases.
  122.  
  123.   In the text the BBS initiating the connect will be referred to as the
  124.   MASTER and the remote BBS will be referred to as the SLAVE.
  125.  
  126.   Each command and exchange will be presented in BNF (Backus-Naur Form)
  127.   which is a context-free grammar widely used to describe computer
  128.   language syntax.
  129.  
  130.   All commands and fields are case insensitive.
  131.  
  132.   Meta-syntactic information
  133.  
  134.     [x]   =    Optional: zero or one x
  135.     (x y) =    Grouping: treat multiple tokens as a single token
  136.     <>      =    Set
  137.  
  138.   Characters:
  139.  
  140.     NUL =    <0x00>
  141.     CNTRL_C =    <0x03>
  142.     TAB =    <0x09>
  143.     CR =    <0x0D>
  144.     LF =    <0x0A>
  145.     CNTRL_Z =    <0x1A>
  146.     SP =    <0x20>
  147.  
  148.   Character sets:
  149.  
  150.     ALPHA =    <'A'-'Z'>
  151.     DIGIT =    <'0'-'9'>
  152.     ALNUM =    ALPHA | DIGIT
  153.     ASCII =    <0x20-0xFF>
  154.     SPACE =    SP | TAB
  155.     8BIT  =    <0x01 - 0xff, except CR, LF, CTRL_Z>
  156.  
  157.   Character sequences:
  158.  
  159.     EOL =    CR | CR LF
  160.  
  161.     NUMBER =    DIGIT | NUMBER DIGIT
  162.     WHITE =    SPACE | WHITE SPACE
  163.  
  164.     ASCII_STR = ASCII | ASCII_STR ASCII
  165.     ALNUM_STR = ALNUM | ALNUM_STR ALNUM
  166.     8BIT_STR  = 8BIT  | 8BIT_STR  8BIT
  167.  
  168.   Throughout this document we will present a verbose translation of the
  169.   grammar highlighting any points that may not be obvious but could
  170.   have significant affect. There will also be examples illustrating what
  171.   can actually be expected.
  172.  
  173.   Section 1 - Establishing connection
  174.  
  175.   When connecting to a BBS the first line the BBS sends must be the
  176.   SID (System IDentifier). The SID is used to determine what features
  177.   are supported by BBS. The existence of the SID implies that the system
  178.   supports reverse forwarding and OK/NO message rejection. There still
  179.   exist old BBS codes which do not present a SID at connect. Refer to
  180.   Section 4 for information on forwarding to these old style BBS sytems.
  181.  
  182.   SID sent by both MASTER and SLAVE
  183.  
  184.     AUTHOR_ID     =  <ASCII_STR, except '[', ']' and '-'>
  185.     AUTHOR_DATA  =  <ASCII_STR, except '[' and ']'>
  186.     FEATURE     =  ALPHA [DIGIT]
  187.     FEATURE_LIST =  FEATURE | FEATURE_LIST FEATURE
  188.     SID      =  "[" AUTHOR_ID "-" [AUTHOR_DATA "-"] FEATURE_LIST [$]"]" EOL
  189.  
  190.  
  191.     The AUTHOR_ID and FEATURE_SET must be present. If the optional
  192.     AUTHOR_DATA is present it must be separated from the other two
  193.     fields by a '-'. AUTHOR_DATA may contain the '-' character.
  194.  
  195.     The AUTHOR_ID and AUTHOR_DATA are typically a portion of the authors
  196.     callsign or BBS name and version number, respectively.
  197.  
  198.     Each FEATURE consists of a letter, denoting the feature and an
  199.     optional number, denoting the feature level. The absence of a
  200.     version number implies version zero.
  201.  
  202.     If BID's are supported, '$' must be the last symbol in the FEATURE_SET.
  203.  
  204.     The recommended minimal support is BID and Hierarchical location
  205.     identifiers. These are necessary for the proper operation of the network.
  206.  
  207.     EXAMPLE
  208.  
  209.       [ZFJ-2.3-H$]
  210.  
  211.   The original prompt received from the SLAVE BBS may contain additional
  212.   information intended for users. As soon as the SID is received by the
  213.   SLAVE BBS it should respond with an abbreviated PROMPT, with the
  214.   ASCII_STR field being empty.
  215.  
  216.   Section 2 - Forwarding
  217.  
  218.   A message can either be rejected or accepted by the SLAVE. There are
  219.   many reasons that the SLAVE my choose to reject a message but the most
  220.   common will be duplicate bid, indicating the SLAVE already has the message.
  221.   Here is an overview of the exchange.
  222.  
  223.  
  224.   ACCEPT EXCHANGE:
  225.  
  226.     MASTER        SLAVE
  227.     ------        -----
  228.             PROMPT
  229.     SEND_CMD
  230.             RESPONSE (OK)
  231.     MESSAGE
  232.             COMMENT
  233.             PROMPT
  234.  
  235.   REJECT EXCHANGE:
  236.  
  237.     MASTER        SLAVE
  238.     ------        -----
  239.             PROMPT
  240.     SEND_CMD
  241.             RESPONSE (NO)
  242.             PROMPT
  243.  
  244.   The SLAVE indicates it's prepared to accept a command by issuing a PROMPT.
  245.   The PROMPT is also used as an an acknowledgement that the last message
  246.   has be received.
  247.  
  248.   The MASTER initiates the message exchange by issuing a a SEND_CMD. This
  249.   command contains all the information necessary for the SLAVE to decide
  250.   whether to ACCE or REJECT the message. It contains message type,
  251.   destination, originator and possibly a bid.
  252.  
  253.     COMMENT =    <ASCII_STR, except '>'>
  254.     PROMPT  =    [COMMENT] ">" EOL
  255.  
  256.     TYPE =    'B' | 'P' | 'T'
  257.     CALLSIGN =    <ASCII_STR, except '@', '.', max length 6>
  258.     LOC =    <ASCII_STR, except '@', '.', max length 6>
  259.     HLOC =    LOC | <HLOC "." LOC, max length 31>
  260.     BBS =    CALLSIGN ["." HLOC]
  261.     TO =    CALLSIGN [WHITE "@" WHITE BBS]
  262.     FROM =    CALLSIGN
  263.     BID =    <ASCII_STR, max length 12>
  264.  
  265.     SEND_CMD =    "S" TYPE WHITE TO [WHITE "<" WHITE FROM] [WHITE "$" BID]
  266.  
  267.  
  268.     HLOC is the hierarchical location of the system. It is defined by
  269.     the document "INTERNATIONAL ROUTING DESIGNATORS", ARRL Networking
  270.     Conference Proceedings xxx.
  271.  
  272.     The TO field commonly takes the following forms:
  273.  
  274.       callsign @ BBS.hloc        ; N6ZFJ @ N6QMY.CA.USA.NA
  275.       category @ distrib        ; WANT @ ALLCA
  276.       category @ BBS.hloc        ; WANT @ N6QMY.CA.USA.NA
  277.       category @ distib.hloc    ; INFO @ ALLCA.CA.USA.NA
  278.  
  279.     The first two are seen most often, but the other two forms are seen.
  280.     The first two forms are also normally associated with the
  281.     message type of PERSONAL and BULLETIN respectively.
  282.  
  283.     White space is required on either side of the '@' and between the
  284.     '<' and the senders callsign. There cannot be white space between
  285.     the '$' and the BID.
  286.  
  287.  
  288.     EXAMPLE
  289.  
  290.       SB WANT @ ALLSCV < N6ZFJ $2345_N6QMY
  291.  
  292.     A "BID" (Bulletin IDentifier) is associated with each Bulletin,
  293.     and may be associated with any Personal message.
  294.  
  295.     If a BID is not given explicitly when the message is entered into
  296.     the system, and the message type requires a BID, one is created
  297.     automatically from the message number and callsign of the system
  298.     into which the message was initially entered.
  299.  
  300.     NOTE:
  301.  
  302.     It is suggested that a generated BID have the form nnn_BBS,
  303.     where nnn is the message number at the originating BBS system,
  304.     and BBS is the callsign of the originating BBS system.
  305.  
  306.     COMMON_BID =    MSG_NUM "_" CALLSIGN
  307.  
  308.     BBS codes are free to create whatever form they wish as long as the
  309.     length doesn't exceed 12 characters.
  310.  
  311.     Messages to a distribution, whether they are bulletins or personal
  312.     messages, must have a BID. Personal messages to a specific user may
  313.     carry a BID if the user supplied one, but will not be given a default
  314.     BID. NTS message never carry a BID.
  315.  
  316.   The SLAVE BBS determines from the SEND_CMD whether or not to accept
  317.   the message. The reasons for rejection is usually that the message
  318.   already exists on the SLAVE system (i.e. a duplicate BID), or possibly
  319.   a system related problem.
  320.  
  321.   Sent by SLAVE in response to SEND_CMD (or by MASTER if in reverse
  322.   forward mode).
  323.  
  324.     RESPONSE =    ACCEPT | REJECT
  325.  
  326.     ACCEPT =    "OK" [ WHITE COMMENT ] EOL
  327.  
  328.     REJECT =    "N" [ "O" ] [ WHITE COMMENT ] EOL
  329.  
  330.     NOTE:
  331.     The syntax of responses has grown in a random fashion. Many BBS programs
  332.     expect to see the entire words "OK" and "NO" while others simply look
  333.     at the first letter. It is suggested that new BBS codes should present the
  334.     words "NO" and "OK", but look for only the first letter. Doing so should
  335.     ensure compatibility with existing BBS codes.
  336.  
  337.     EXAMPLE
  338.       Master:  SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY
  339.       Slave:   NO duplicate bid
  340.       Slave:   >
  341.  
  342.       Master:  SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY
  343.       Slave:   OK #32190
  344.       Master:  message body
  345.       Master:  /EX
  346.       Slave:   Message being held for sysop review
  347.       Slave:   >
  348.  
  349.     It is required that the "OK" and "NO" strings be followed by white
  350.     space or EOL. Some BBS programs will fail to recognize them otherwise.
  351.  
  352.     EXAMPLE
  353.       Master:  SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY
  354.       Slave:   NO, already have it
  355.       Slave:   >
  356.  
  357.       This would fail with some existing BBS codes due to
  358.       the comma following the "NO" string.
  359.  
  360.  
  361.   If the SLAVE BBS responds with a REJECT condition the message should
  362.   not be sent and the MASTER should ignore any response from the SLAVE
  363.   until PROMPT is encountered. The MASTER can then submit a new SEND_CMD,
  364.   initiate reverse forwarding or disconnect.
  365.  
  366.   Once the SLAVE has issued the ACCEPT response, the MASTER BBS
  367.   should immediately send the message subject, routing headers,
  368.   message body and EOM. The SLAVE will acknowledge with PROMPT
  369.   once it receives an EOM.
  370.  
  371.     Message Routing Header
  372.  
  373.     SUBJECT =  <ASCII_STR, max length 79> EOL
  374.     YEAR    =  DIGIT DIGIT
  375.     MONTH   =  DIGIT DIGIT
  376.     DAY     =  DIGIT DIGIT
  377.     HOUR    =  DIGIT DIGIT
  378.     MINUTE  =  DIGIT DIGIT
  379.  
  380.     STAMP   =    "R:" YEAR MONTH DAY "/" HOUR MINUTE ["Z"]
  381.     MSG_NUM =    <NUMBER, range 1 - 65535 (0xFFFF)>
  382.  
  383.     HEADER1 =    STAMP WHITE MSG_NUM "@" BBS EOL
  384.     HEADER2 =    STAMP WHITE "@:" BBS WHITE [ASCII_STR] "#:" MSG_NUM [ASCII_STR]
  385.     HEADER  =    HEADER1 | HEADER2
  386.  
  387.     Message structure
  388.  
  389.     HEADERS =    HEADER | HEADERS HEADER
  390.     EOM     =    (CNTRL_Z EOL) | (EOL "/EX" EOL)
  391.     BODY    =    8BIT_STR | BODY EOL 8BIT_STR
  392.     MESSAGE =    SUBJECT [HEADERS] EOL [BODY] EOM
  393.  
  394.     EXAMPLE
  395.  
  396.       Example message
  397.       R:930108/1729 @:N6QMY.#NOCAL.CA.USA.NA Fremont #:1114 Z:94536
  398.       R:930108/1259 1530@KA6FUB.#NOCAL.CA.USA.NA
  399.       R:930107/1638z @:WD6CMU.#NOCAL.CA.USA.NA "OSKbox" #:10576 Z:94805
  400.       R:930107/1045 50724@WX3K.#NOCAL.CA.USA.NA
  401.  
  402.       message body will go here, the blank line above separates the
  403.       body from the routing headers. When the body is through it should be
  404.       terminated as follows:
  405.       /EX
  406.  
  407.     NOTE:
  408.     Both forms of the header described above are seen, and should be parsed.
  409.     In either case there may be comments found at the end of the header line,
  410.     or between the BBS and the MSG_NUM entries in HEADER2.
  411.  
  412.     HEADER2 is derived from the header form used in early BBS codes.
  413.     it allows addtional information to be passed in the header and parsed
  414.     if desired. Some examples of these additional fields seen are:
  415.  
  416.       Z:zipcode
  417.       O:orginator
  418.       $:bid
  419.       C:name_of_sysops_cat
  420.  
  421.     NOTE:
  422.     The time stamp in the routing header must be in GMT. Some existing BBS
  423.     codes provide the time stamp in other than GMT, and may include a time
  424.     zone indicator after the time stamp. This should be considered in the
  425.     design of header parsers.
  426.  
  427.     Each system that handles the message places it's routing header
  428.     at the top of the message headers before passing the message to
  429.     the next BBS. The headers must begin in column 1. A blank line
  430.     separates the routing headers from the body of the message.
  431.  
  432.     The last (oldest) routing header shows the BBS where the message
  433.     originated. This header is the only source for this information.
  434.     The information about the originating BBS is used to create a
  435.     return address for reply messages.
  436.  
  437.     Here are two examples of the same header, in the two different formats:
  438.  
  439.       R:930101/0000 1530@KA6FUB.#NOCAL.CA.USA.NA
  440.       R:930101/0000 @:KA6FUB.#NOCAL.CA.USA.NA #:1530
  441.  
  442.     These examples show the different syntax for the message number and
  443.     originating BBS address. All fields not shown in the examples are
  444.     optional at the discretion of the sysop.
  445.  
  446.   Section 3 - Reverse forwarding
  447.  
  448.   Once all messages have either been successfully forwarded from the MASTER
  449.   to the SLAVE, or been rejected by the SLAVE, the MASTER may accept
  450.   messages from the SLAVE. i.e. the MASTER and SLAVE exchange roles.
  451.   This is called "reverse forwarding".
  452.  
  453.   ACCEPT EXCHANGE:
  454.  
  455.     MASTER        SLAVE
  456.     ------        -----
  457.             PROMPT ">"
  458.     REV_FWD "F>"
  459.             SEND_CMD
  460.     RESPONSE "OK"
  461.             MESSAGE
  462.     COMMENT
  463.     REV_FWD "F>"
  464.  
  465.   REJECT EXCHANGE:
  466.  
  467.     MASTER        SLAVE
  468.     ------        -----
  469.             PROMPT ">"
  470.     REV_FWD "F>"
  471.             SEND_CMD
  472.     RESPONSE "NO"
  473.     REV_FWD "F>"
  474.  
  475.   The MASTER indicates that it is ready to accept a message by answering
  476.   the SLAVE's PROMPT, ">",  with a REV_FWD command, "F>". At that point the
  477.   SLAVE issues a SEND_CMD and the process continues as described in
  478.   section 2 but with the rolls of MASTER and SLAVE reversed. The only
  479.   difference is that the MASTER will always respond with REV_FWD in
  480.   place of PROMPT to indicate successful transfer.
  481.  
  482.     REV_FWD =    "F>" EOL
  483.  
  484.   The reverse forwarding phase is optional and is under the control of
  485.   the MASTER. It can be terminated by any of the following:
  486.  
  487.     SLAVE disconnects
  488.  
  489.     SLAVE sends anything other than a legal SEND_CMD
  490.  
  491.     MASTER disconnects
  492.  
  493.     MASTER sends anything other than "F>".
  494.  
  495.   Section 4 - Forwarding to old BBSs
  496.  
  497.   If the SLAVE does not return a SID then it is assumed that it will
  498.   not support BIDs nor OK/NO message rejection.
  499.  
  500.   The SLAVE indicates it is prepared to accept a command by issuing a
  501.   PROMPT. This PROMPT is also an acknowledgement that the last message
  502.   has been received.
  503.  
  504.   The MASTER initiates the message exchange by issuing a SEND_CMD with no
  505.   HLOC or BID. The SLAVE has no way to reject the message so the MASTER
  506.   proceeds to send the message subject and body without expecting
  507.   acknowlegement from the SLAVE.
  508.  
  509.   Since the SLAVE assumes a user is entering the message, it will display
  510.   prompts to lead the user through the message sending process, asking for
  511.   a subject, prompting for the message body, etc. The MASTER should
  512.   consider this text to be part of the PROMPT and ignore it.
  513.  
  514.   As in Section 2, the MASTER waits until PROMPT is received. This is the
  515.   acknowledgement that the message has been recieved and the next message
  516.   can be sent.
  517.  
  518.   When the MASTER has no additional messages to send it disconnects
  519.   from the SLAVE. Reverse forwarding is not supported in this situation.
  520.  
  521.   Section 5 - Error Conditions
  522.  
  523.   When an error of any nature is detected by either the MASTER or the SLAVE,
  524.   that station will disconnect at once, without issuing a PROMPT.
  525.  
  526.  
  527.   Section 6 - BNF Summary
  528.  
  529.   Meta-syntactic information.
  530.  
  531. [x]         =    Optional Zero or one x.
  532. (x y)         =    Grouping.  Treat multiple tokens as single token.
  533. <>         =    Set.
  534.  
  535.   Characters of interest.
  536.  
  537. TAB         =    <0x09>
  538. LF         =    <0x0a>
  539. CR         =    <0x0d>
  540. CNTRL_Z      =    <0x1a>
  541. SP         =    <0x20>
  542.  
  543.   Character sets of interest.
  544.  
  545. ALPHA         =    <'A' - 'Z', 'a' - 'z'>
  546. DIGIT         =    <'0' - '9'>
  547. ALNUM         =    ALPHA | DIGIT
  548. ASCII         =    <0x20 - 0xff>
  549. SPACE         =    SP | TAB
  550. 8BIT         =    <0x01 - 0xff, except CR, LF, CTRL_Z>
  551.  
  552.   Character sequences of interest.
  553.  
  554. EOL         =    CR | CR LF
  555.  
  556. NUMBER         =    DIGIT | NUMBER DIGIT
  557. WHITE         =    SPACE | WHITE SPACE
  558.  
  559. ASCII_STR    =    ASCII | ASCII_STR ASCII
  560. ALNUM_STR    =    ALNUM | ALNUM_STR ALNUM
  561. 8BIT_STR     =    8BIT  | 8BIT_STR  8BIT
  562.  
  563.   System identifier syntax.
  564.  
  565. AUTHOR_ID    =    <ASCII_STR, except '[', ']', '-'>
  566. AUTHOR_DATA  =    <ASCII_STR, except '[', ']'>
  567. FEATURE      =    ALPHA [DIGIT]
  568. FEATURE_LIST =    FEATURE | FEATURE_LIST FEATURE
  569. SID         =    "[" AUTHOR_ID ["-" AUTHOR_DATA] "-" FEATURE_LIST "]" EOL
  570.  
  571.   System Prompt syntax.
  572.  
  573. COMMENT      =     <ASCII_STR, except '>'>
  574. PROMPT         =     [COMMENT] ">" EOL
  575.  
  576.   Send Command syntax.
  577.  
  578. TYPE         =    'B' | 'P' | 'T'
  579. CALLSIGN     =    <ASCII_STR, except '@', '.', max length 6>
  580. LOC         =    <ASCII_STR, except '@', '.', max length 6>
  581. HLOC         =    <LOC | HLOC "." LOC, max length 31>
  582. BBS         =    CALLSIGN ["." HLOC]
  583. TO         =    CALLSIGN [("@" | WHITE "@" WHITE) BBS]
  584. FROM         =    CALLSIGN
  585. BID         =    <ASCII_STR, max length 12>
  586. SEND         =    "S" TYPE WHITE TO [WHITE "<" WHITE FROM] [WHITE "$" [BID]]
  587.  
  588.   Message syntax.
  589.  
  590. SUBJECT   =  <ASCII_STR, max length 79> EOL
  591.  
  592. YEAR      =  DIGIT DIGIT
  593. MONTH      =  DIGIT DIGIT
  594. DAY      =  DIGIT DIGIT
  595. HOUR      =  DIGIT DIGIT
  596. MINUTE      =  DIGIT DIGIT
  597. STAMP      =  "R:" YEAR MONTH DAY "/" HOUR MINUTE
  598. MSG_NUM   =  <NUMBER, range 1 - 65535>
  599. HEADER1   =  STAMP WHITE MSG_NUM "@" BBS EOL
  600. HEADER2   =  STAMP WHITE "@:" BBS WHITE [ASCII_STR] "#:" MSG_NUM [ASCII_STR]
  601. HEADER      =  HEADER1 | HEADER2
  602. HEADERS   =  HEADER | HEADERS HEADER
  603.  
  604. BODY      =  8BIT_STR | BODY EOL 8BIT_STR
  605. EOM      =  (CTRL_Z EOL) | (EOL "/EX" EOL)
  606. MESSAGE   =  SUBJECT [HEADERS] EOL [BODY] EOM
  607.  
  608.   Standard message identification syntax.
  609.  
  610. MSG_ID         =    MSG_NUM "_" CALLSIGN
  611.  
  612.  
  613.   Section 7 - Feature Letter Use
  614.  
  615. Feature $:
  616.  
  617.   Supports BIDs.
  618.  
  619. Feature A:
  620.  
  621.   F6FBB - Acknowledge for personal messages.
  622.  
  623. Feature B:
  624.  
  625.   F6FBB - Binary messages supported.
  626.  
  627. Feature C:
  628.  
  629.   Obsolete:  Supports automatic distribution of current date / time.
  630.          (W0RLI, K0ZXF)
  631. Feature F:
  632.  
  633.   F6FBB - Batch forwarding protocol.
  634.  
  635. Feature H:
  636.  
  637.   Supports Hierarchical Location designators.
  638.  
  639. Feature I:
  640.  
  641.   Some transport mechanisms do not identify the calling station in the
  642.   protocol as AX25 does. To handle this situation, a "null command"
  643.   is defined as a line beginning with ';'. This allows the sending station
  644.   to send callsigns to satisfy the regulations for station identification.
  645.  
  646.   EXAMPLE
  647.  
  648.     ; W5SMM de W0RLI
  649.  
  650.   The receiving station must ignore such lines.
  651.  
  652. Feature L:
  653.  
  654.   G1nna - Compression.
  655.  
  656. Feature M:
  657.  
  658.   For AA4RE systems:
  659.  
  660.   Basic level ("M0")
  661.     MID = message identifier
  662.     Every message has a MID.
  663.     The MID looks like a "generated" BID (example 12345_AA4RE).
  664.     The "M" letter in the SID indicates that a MID is to be transmitted
  665.     with messages that have no BID.
  666.  
  667.     Processing:
  668.  
  669.     If a send command is received by a BBS with a MID, the program
  670.     should determine if it is a duplicate.  If it is, the program
  671.     should respond with the usual "NO" as if it was matching a BID.
  672.  
  673. Feature R:
  674.  
  675.   AA4RE - Extended reject responses.
  676.  
  677.   OK
  678.     Yes, send to me.  Note that no number is required.    This may
  679.     help eliminate phantom message numbers.
  680.  
  681.   NO
  682.     This is a real dupe
  683.   REJECT
  684.     I can't handle this
  685.   LATER
  686.     Send to me later ...
  687.  
  688.   The LATER is useful when you are already receiving a bulletin on one
  689.   connect and someone else tries to send you the same bulletin.
  690.  
  691.   REJECTed messages should be called to the attention of the SYSOP
  692.   to see why the reject occurs.
  693.  
  694.   The difference between NO and REJECT is whether or not SYSOP attention
  695.   is needed.
  696.  
  697.   Abreviations are alloed: 1 Letter only ... O N L R
  698.  
  699.   There must be a blank after the word or letter.  This one is fine:
  700.     N Already have it.
  701.   This one is not correct:
  702.     REJECT, Something wrong
  703.   The comma is not allowed.
  704.  
  705. Feature S:
  706.  
  707.   AA4RE - Extended "S" commands.
  708.  
  709. Feature X:
  710.  
  711.   W0RLI - Supports ihave/iwant compressed batch forwarding.
  712.  
  713.      A standard for Data compression during the forwarding
  714.      of messages in the Amateur Radio BBS Network.
  715.  
  716.      o ihave/iwant variable batch size protocol
  717.      o Feature letter X, commands SS, SX, SY.
  718.      o lzh compression
  719.  
  720. ----------------------------------------------------------------------------
  721.      Command Definitions and BNF description.
  722. ----------------------------------------------------------------------------
  723.  
  724.   N         = INTEGER, size 32 bits.
  725.   protocol   = TBD
  726.   batch_size = N
  727.   file_size  = N
  728.   msg_count  = <0 - 25>
  729.  
  730.   id         = BID | MID CR
  731.   ids         = id | ids id
  732.  
  733.   byte         = <0x00 - 0xff)
  734.   bytes      = byte | bytes byte
  735.  
  736.   ihave = "SX " msg_count [" " protocol] [" " batch_size] CR [ids]
  737.   iwant = "SY " msg_count CR [ids]
  738.   isend = "SS " file_size CR bytes
  739.  
  740.   For ihave:
  741.   Protocol and batch_size not used in initial implementation.
  742.   Default protocol is: lzh compressed export/import file.
  743.  
  744.   For iwant:
  745.   SY means want only these.
  746.  
  747.   Note that the SS command must terminate with CR, without LF.
  748.  
  749.   RFC-822 header fields used are:
  750.  
  751.   To:
  752.   From:
  753.   Subject:
  754.   Message-ID:
  755.   X-msgtype:
  756.   X-BID:
  757.  
  758. ----------------------------------------------------------------------------
  759.      The basic interchange (example):
  760. ----------------------------------------------------------------------------
  761.  
  762.   bn are BIDs (or MID if message has no BID).
  763.   m: is master, s: is slave.
  764.  
  765. m: SX 5
  766. m: b1
  767. m: b2
  768. m: b3
  769. m: b4
  770. m: b5
  771.  
  772. s: SY 3
  773. s: b1
  774. s: b3
  775. s: b5
  776.  
  777. m: SS 26545
  778. m: <sends 26545 byte file>
  779.  
  780. In the case of any error, the station noticing the error must disconnect.
  781.  
  782. ----------------------------------------------------------------------------
  783.      With more detail of one implementation (MB/SERVER processing)
  784. ----------------------------------------------------------------------------
  785.  
  786.   Maximum batch size defined globally (default), and per link.
  787.   Ability to turn compression on/off (add/drop feature X in SID).
  788.  
  789.  
  790. >From sending side:
  791.  
  792.    MB:
  793.  
  794.    Scan messages to find a batch just larger than max batch size.
  795.    Keep record numbers and cc: id in list.
  796.    Send ihave.
  797.    Receive iwant.
  798.    Mark all messages in ihave and not in iwant as forwarded (dup bid).
  799.    Pass iwant list to SERVER in file.
  800.    Wait for server acknowledge.
  801.  
  802.    SERVER:
  803.  
  804.    Create export file.
  805.    Compress export file.
  806.    Signal MB that compressed file ready to send.
  807.  
  808.    MB:
  809.  
  810.    Send isend, send the file.
  811.    Receive prompt.
  812.    Mark all messages in iwant as forwarded.
  813.  
  814. >From receiving side:
  815.  
  816.    MB:
  817.  
  818.    Receive ihave.
  819.    Check bids in ihave.
  820.    For all non-dup bids, make iwant list.
  821.    Send iwant.
  822.    Receive compressed file.
  823.    Signal SERVER import file available.
  824.    Send prompt.
  825.  
  826.    SERVER:
  827.  
  828.    Decompress file, import messages.
  829.  
  830.  
  831.  
  832.   Section 8 - Import / Export files.
  833.  
  834. Import/Export files may contain any number of messages.
  835. Each message is terminated by "/EX" EOL
  836.  
  837.   RFC-822 header use in import/export files.
  838.  
  839. The standard RFC-822 keywords which must be supported are:
  840.  
  841.   To:
  842.   From:
  843.   Subject:
  844.   Message-ID:
  845.   cc:
  846.  
  847. Extension keywords which must be supported are:
  848.  
  849.   X-msgtype:       (W0RLI)
  850.   X-BBS-Msg-Type:  (JNOS)
  851.  
  852.   X-BID:       (W0RLI)
  853.  
  854.   X-BBS-Hold:       (JNOS)
  855.   X-Forwarded-To:  (JNOS)
  856.  
  857. END OF SPEC
  858.  
  859.  
  860. -- 
  861.  
  862. Hank Oredson @ Mentor Graphics
  863. Internet     : hank_oredson@mentorg.com
  864. Amateur Radio: W0RLI@W0RLI.OR.USA.NA
  865.